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Comparison  of 
AFITPAC  versus  NOS 
and  a 

Packet  Radio  Network  Design 

I.  Introduction 

1. 1  Background 

The  Air  Force  Logistics  Command  (AFLC)  sponsored  software  development 
work  at  the  Air  Force  Institute  of  Technology  (AFIT)  for  Packet  Radio  Networks 
(PRNET)  in  1988(14,  20),  1989(15)  and  1990(10).  A  PRNET  is  a  ooUection  of 
computers  using  radio  stations  as  their  communications  media.  PRNETs  are  used 
to  connect  rx)mputers  that  are  unable  to  be  hard  wired.  For  example,  portable  or 
mobile  computers  and  systems  located  in  areas  where  telephone  lines  are  of  poor 
quality,  out  of  service,  or  non-existent.  The  AFIT  work  resulted  in  Marsh  creating  a 
software  package,  called  AFITPAC,  which  provided  a  menu  driven  user  interface  to 
the  PRNET(15).  This  enabled  the  user  to  perform  tasks,  such  as  transferring  files, 
setting  terminal  node  controller  (TNC)  parameters,  and  establishing  connections, 
just  by  using  the  function  keys  displayed  at  the  bottom  of  the  scrtxm.  Then,  in  1990, 
Geier  modified  the  package  to  include  an  automatic/ adaptive  routing  algorithm(10, 
11).  The  routing  algorithm  builds  a  table  of  Packet  Radio  Units  (PRUs)  available  on 
the  network  and  the  routes  used  to  got  to  them(10,  11).  This  table  is  then  displayed 
on  screen  to  facilitate  user  connections  to  remote  PRUs.  Prior  to  this  ciiangc,  the  user 
had  to  have  knowledge  of  the  network  topology  in  order  to  establish  a  connection, 
and  the  user  was  required  to  (uiter  the  routing  table  manually  into  the  computer. 
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In  order  for  this  package  to  work  it  needs  to  transmit  and  receive  special 
packets  on  the  network.  These  packets  contain  a  cxjntrol  character  at  the  beginning 
of  the  data,  which  marks  the  packet  as  routing  information.  The  receiving  Packet 
Radio  Unit  (PRU)  can  then  process  this  information  to  modify  its  routing  table. 
Geier’s  packets  travel  the  network  just  as  other  information  packets  do  and  add 
overhead  traffic,  for  route  management,  to  the  normal  PRNET  traffic.  Geicr  tested 
his  software  in  the  Umited  AFIT  PC  laboratory  environment  using  three  PRUs. 
He  demonstrated  that  the  routing  algorithm  performed  as  (xpected  on  the  three 
PRUs.  However,  the  AFLC  PRNET  was  designed  for  disaster  ndief  efforts  and 
wartime  a)ntingencies(  10,  15).  This  imphes  a  PRNET  c.omposed  of  a  large  number  of 
portable  units.  If  the  routing  algorithm’s  overhead  traffic  incr(;as(^s  drastically  imder 
these  (X)nditions,  it  would  interh^re  with  vital  information  traffic  on  the  PRNET. 
resulting  in  long  (hdays  in  message  transportation  or  blocked  connections.  A  traffic 
flow  analysis  of  Geier’s  software  on  the  AFLC  PRNET  must  be  cx)mpleted  before 
confidently  placing  the  package  in  the  operational  <3ivironment(10).  The  information 
gathered  from  such  an  analysis  could  be  used  in  the  development  of  software  packages 
that  are  more  channel  efficient. 

1.2  Problem  Descnplion 

The  challtuige  is  to  develop  a  method  of  traffic  flow  analysis  for  software  pack¬ 
ages  used  in  a  packet  radio  network.  One  possible  solution  would  be  to  coordinate 
with  local  amateur  radio  operators  to  use  their  PRUs.  After  some  field  research,  the 
author  determined  that  the  local  amateurs  have  permanent  radio  stations  in  their 
homes.  If  they  have  portable  radio  stations,  in  general  their  computer  systems  are 
not  portable.  This  type  of  fixed  topology  PRNET  would  not  repr(;scnt  the  opera¬ 
tional  environment  desired,  because  the  PRUs  need  to  be  portable,  and  therefore, 
makes  a  poor  test  condition.  Another  possibility  would  be  to  create  a  computer 
model  of  the  PRNET  that  would  allow  for  both  stationary  and  portable  PRUs. 
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Modeling  tools  are  hard  pressed  to  keep  up  with  the  dramatic  changes 
in  the  nature  of  computer  networks  and  their  application  environments. 

. . .  Modelers  purchase  their  own  tools  or  services,  but  most  packages  only 
solve  a  piece  of  the  computer  networking  puzzle.  Much  of  the  effort  goes 
into  models  that  try  to  portray  the  operation  of  complex  networks  and 
architectures  supporting  a  wide  variety  of  heterogeneous  equipment  and 
software.  (16) 

Mitchell  G.  Spiegel 

As  Spiegel  stated,  most  network  modeling  tools  do  not  accommodate  all  the 
requirements  of  a  particular  modeler’s  project.  The  biggest  hmitation  to  network 
modeling  tools  is  they  can  not  incorporate  other  software  packages.  Therefore,  the 
problem  is  to  design  and  develop  a  computer  model  of  a  packet  radio  network  with 
changing  topology  that  will  interface  with  Geier’s  automatic/ adaptive  routing  algo¬ 
rithm  package  and  Karn’s  Network  Operating  System(21),  NOS  package.  NOS  is 
examined  as  a  possible  alternative  to  AFITPAC  because  it  implements  many  of  the 
standard  applications  of  Defense  Data  Network  (DDN)  hosts  and  its  C  source  code 
is  readily  available. 

1.3  Summary  of  Current  Knowledge 

Most  of  the  signiftcant  work  in  the  packet  radio  network  simulation  is  spon¬ 
sored  by  Defense  Advanced  Research  Projects  Agency  (DARPA).  The  work  includes 
a  package  called  PC-NETSIM  developed  for  DARPA  in  1989,  by  Rockwell  Inter¬ 
national  Colhns  Defense  Communications(l,  2).  This  discrete-event  simulator  pro¬ 
vides  an  artificial  execution  environment  for  the  actual  protocols  to  be  used  in  the 
PRNET(2).  Unfortunately,  PC-NETSIM,  simulates  a  packet  radio  network  that 
uses  different  radio  system  technology,  specifically  a  direct-sequence  spread  spec¬ 
trum  system(l,  2),  than  the  AFLC  PRNET,  which  uses  Audio-Frequency-Shift- 
Keying  (AFSK)  broadca.st  using  Frequency  Modulation  (FM)(12).  Furthermore, 
PC-NETSIM  simulates  a  system  using  a  Pure- Aloha  channel  access  scheme  and  the 
AFLC  PRNET  uses  a  Carrier  Sense  Multiple  Access  (CSMA)  scheme.  The  differ- 
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ences  in  the  performance  of  these  two  modulation  and  channel  access  schemes  would 
cause  the  simulation  results  to  represent  the  performance  of  the  software  packages 
inaccurately.  For  a  discussion  of  the  performance  differences  between  Pure-Aloha 
and  CSMA  see  Tanenbaum(19). 

1.4  Assumptions  &  Scope 

This  project  is  witten  using  and  MODSIM  These  languages  were 

chosen  for  the  following  reasons.  They  are  portable  to  all  of  the  hardware  platforms 
currently  in  use  in  PRNETs(4).  MODSIM  11^^  also  provides  an  interface  to  C'*"*' 
which  allows  the  original  software  modules  of  Geier’s  software  to  be  used.  However, 
MODSIM  uses  different  data  t3rpes  than  C'*"*'  requiring  modifications  to  some 
variables  in  the  AFITPAC  software.  Table  1.1  shows  the  correspondence  of  data 
types  between  the  two  languages.  Each  simulated  PRU  will  be  running  its  own  copy 


MODSIM  II^^ 

C++ 

INTEGER 

long 

REAL 

double 

BOOLEAN 

unsigned  char 

CHAR 

unsigned  char 

STRING 

char  *  to  “C++” 

ARRAY  OF  CHAR 

string  from  “C‘+” 

ANYREC  or  ANYOBJ 

enumeration 

unsigned  char 

Table  1.1.  MODSIM  II^^  data  types  and  their  corresponding  C'*"*'  data  types 

of  the  AFITPAC  software.  This  may  cause  conflicts  with  the  video  display. 

Therefore,  all  functions  causing  video  input /output  will  be  removed.  Problems 
may  also  arise  with  the  AFITPAC  software’s  use  of  the  file  system  to  store  infor¬ 
mation,  because  all  of  the  PRUs  will  be  trying  to  read  and  write  to  the  same  file. 
Any  of  AFITPAC’s  functions  that  perform  file  I/O  will  be  modified  to  accept  an 

’MODSIM  II  is  a  trademark  and  service  of  CACI  Products  Company 
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argument  for  a  filename  to  correct  this  problem.  Thus  allowing  the  simulation  to 
pass  unique  filenames  to  each  copy  of  the  software. 

The  researcher’s  computer  model  will  simulate  the  portable  radio  units,  the 
radio  signal  connectivity  between  PRUs,  and  TNG  functions.  For  the  purposes  of  this 
project,  all  PRUs  are  assumed  to  have  equal  transmitter  and  receiver  capabihties  and 
the  portable  units  are  off  the  air  while  relocating,  to  avoid  the  problem  of  connection 
failures  due  to  a  change  in  network  topology. 

1.5  Organization 

The  remaining  thesis  chapters  are  organized  as  follows: 

•  Chapter  II  is  a  comparison  between  AFITPAC(IO),  a  software  package  written 
by  Marsh  and  Geier,  and  N0S(21),  a  software  package  written  by  Phil  Karn 
and  others. 

•  Chapter  III  is  a  discussion  of  the  model  design  and  methodology. 

•  Chapter  IV  concludes  with  findings  and  recommendations. 
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II.  Comparison  of  AFITPAC  and  NOS 


2. 1  Introduction 

In  the  process  of  designing  a  PRNET  simulation,  other  packet  radio  programs 
were  examined.  Looking  at  other  software  packages  revealed  similarities  in  their 
structures  and  performance.  The  similarities  provided  a  better  concept  of  what 
components  a  PRNET  model  needed.  The  name  of  a  particular  software  package 
was  repeatedly  mentioned  during  the  search  for  information  on  packet  radio  tech¬ 
nology  .  The  package  is  the  Network  Operating  System  which  is  called  NOS  in  it 
latest  version.  Older  versions  of  the  package  were  called  NET  or  KA9Q.  A  copy 
of  the  source  code  was  obtained  from  the  DDN,  from  host  ucsd.edu,  and  the  exe¬ 
cutable  was  downloaded  from  CompuServe®.  This  version  of  the  program  is  called 
NOS  VIEW,  and  is  packaged  by  Ian  Wade(21).  NOS  VIEW  adds  a  Terminate- and- 
Stay-Resident  (TSR)  program  to  NOS  which  allows  the  user  to  view  any  part  of  the 
NOS  documentation  on-hne.  Although  this  is  not  the  only  public  domain  packet 
radio  software  available,  it  does  seem  to  be  the  most  comprehensive.  The  fact  that 
NOS  incorporates  many  of  the  different  protocols  and  applications  currently  used 
on  packet  radio  networks  and  on  the  DDN  and  its  abihty  to  act  as  a  gateway  be¬ 
tween  the  two  networks(14)  makes  it  a  possible  alternative  to  AFITPAC.  Therefore, 
a  comparison  of  how  both  packages  meet  the  AFLC  software  requirements  follows. 

2.2  How  NOS  Compares  to  AFITPAC  Requirements 

The  hst  below  enumerates  the  requirements  for  the  AFLC  packet  radio  network 
as  presented  by  Marsh  work(15). 
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1.  The  system  should  be  easy  to  use  with  only  minimal  training. 

2.  The  network  routing  algorithm  should  provide  a  route  for  transmission  of  messages  even 
when  there  is  not  a  direct  route  available  between  source  and  destination. 

3.  Messages  will  be  encrypted  for  transmission. 

4.  The  system  will  provide  archival  storage  of  messages  that  are  transmitted  or  received. 

5.  The  system  should  provide  a  transmit  message  queue  so  that  multiple  messages  c^ul  be 
transmitted  with  little  operator  intervention.  The  queue  should  be  able  to  hold  at  least 
twenty  messages. 

6.  Queued  messages  that  are  not  able  to  be  transmitted  will  be  flagged  for  the  operators 
attention. 

7.  The  system  should  provide  for  reception  messages  whether  the  position  is  attended  or  not. 

8.  The  operator  interface  to  the  program  should  be  menu  driven  with  a  data  window  so  the 
operator  can  see  what  is  being  transmitted  or  received. 

9.  The  operator  interface  should  have  help  screens  as  necessary. 

10.  A  converse  mode  should  be  provided  to  allow  interactive  communication  between  two  node 
operators. 

11.  A  direct  connection  capability  between  the  TNC  and  the  GILLAROO,  via  the  packet  radio 
system  computer,  should  be  incorporated  into  the  system  software  to  allow  for  a  secure 
converse  mode  for  the  system.  ' 

12.  A  system  operator  handbook  will  be  provided.  It  will  include  system  wiring  diagrams  and 
a  software  user’s  guide. 


Figure  2.1.  AFLC  Requirements  for  the  Packet  Radio  Network  Software 

The  researcher  will  demonstrate  how  the  NOSVIEW  implementation  of  NOS 
meets  each  of  the  AFLC  requirements.  For  clarity  it  is  useful  to  define  a  number  of 
terms  before  beginning  the  comparison. 

GILLAROO  -  cryptographic  personal  computer  board  that  encrypts  data,  by  using 
a  key.  The  data  is  converted  into  pairs  of  output  characters.  All 
characters  are  ASCII  printable  text,  the  only  control  characters  are 
CTRL-Q,  CTRL-S,  and  CTRL-Z(15). 

KISS  -  a  protocol  for  computer  to  TNC  communications.  It  allows  the 

computer  to  control  all  of  the  AX. 25  functions  and  the  contents  of 
the  High  Level  Data  Link  Control  (HDLC)  frames  transmitted  and 
received(7). 
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RFC  - 


^{Request  for  Comments)  the  name  of  a  series  of  notes  that  contain 
surveys,  measurements,  ideas,  techniques,  and  observations,  as  well 
as  proposed  and  accepted  Internet  protocols  standards.  RFCs  are 
edited  but  not  refereed.  They  are  available  across  the  Internet. (8)” 

PK-232  -  Z-80  based  TNC  manufactured  by  Advanced  Electronics  AppUca- 

tions,  Inc. 

For  the  purposes  of  this  comparison  Captain  Marsh’s  evaluation  of  AFITPAC’s  abil¬ 
ity  to  meet  each  requirement  will  be  used.  All  material  relating  to  AFITPAC  is 
directly  quoted  from  Marsh(15)  and  the  figures  and  tables  referenced  therein  are  not 
provided. 

2.2.1  Requirements  (1),  (8),  &  (9)  (1)  The  system  should  be  easy  to  use 
with  only  minimal  training.  (9)  The  operator  interface  should  have  help  screens  as 
necessary.  (8)  The  operator  interface  to  the  program  should  be  menu  driven  with  a 
data  window  so  the  operator  can  see  what  is  being  transmitted  or  received. 

AFITPAC  -  (1)  The  system  is  relatively  easy  to  use  but  some  knowledge  of  how  packet 
radio  operates  is  necessary  to  get  the  most  advantage  of  the  system.  This  in¬ 
formation  is  supplied  through  a  brief  users  manual  contained  on  the  AFITPAC 
program  disk. (15)  (8)  The  program  is  menu  driven  (figure  6)  via  the  function 
keys  which  are  displayed  across  the  bottom  of  the  screen.  A  data  window 
covers  the  upper  portion  of  the  screen  (lines  3  through  18,  80  columns)  and 
is  used  for  displaying  all  received/transmitted  data  along  with  any  system 
command  responses(15).  (9)  Help  screens  explaining  function  key  choices 
are  available  (press  FIO)  for  all  menus.  The  main  menu  help  screen  also 
has  a  second  screen  listing  some  of  the  PK-232  commands  and  how  to  use 
them.  All  screens  can  easily  be  changed  by  changing  the  screens  listed  in  the 
HELP.C  module  and  recompiling  the  program(15). 


2-3 


NOS  - 


The  user  has  t  'o  different  ways  in  which  to  interact  with  the  system;  1)  a 
menu  driven  bulletin  board  system,  see  Figure  2.2,  and  2)  issuing  commands 
at  the  net>  prompt.  Both  interfaces  use  the  computer’s  display  screen  and 
each  session  uses  all  25  lines  to  display  transmitted  and  received  information. 
The  bulletin  board  system  is  straight  forward  and  easy  to  use  with  detailed 
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Figure  2.2.  The  NOS  Bulletin  Board  System  Interface  Screen 


help  available  for  each  command.  This  help  is  supplied  through  the  use  of 
the  Help  command.  The  syntax  is  H  command,  with  command  as  any  of 
the  menu  choices.  NOS  then  displays  the  contents  of  the  command.HLP 
file.  This  option  is  available  whether  attached  locally  or  from  a  remote 
site  to  the  system.  The  net>  command  prompt  offers  a  listing  of  the  top 
level  commands  available  by  typing  help  or  f.  Slightly  more  detailed  help  is 
available  on  each  command  by  typing  command  ?.  The  net>  command 
line  is  only  available  on  the  machine  that  is  running  NOS,  and  not  available 
from  remote  sites. 

The  most  detailed  level  of  help  is  available  by  using  the  NOSVIEW  TSR.  To 
activate  the  TSR  press  the  Right  Shift  key  and  the  Spacebar  simultaneously. 
Then  select  the  file  to  be  viewed.  Each  file  in  the  NOSVIEW  directory  is 
named  after  a  command  in  NOS  and  contains  the  entire  documentation  for 
the  command  as  compiled  by  Ian  Wade(21). 

The  individual  responsible  for  installing  the  NOSVIEW  package  needs  to  be 
knowledgeable  about  packet  radio  network  and  Transmission  Control  Proto¬ 
col  (TCP)\Internet  Protocol  (IP)  network  operations.  There  are  a  number 
of  parameters  that  can  bo  set  that  will  have  an  impact  on  the  performance 
of  the  network.  Help  in  setting  up  and  configuring  NOS  will  soon  be  avail¬ 
able  in  the  form  of  book  titled,  NOSintro:  The  Definitive  Primer  for  the 
KA9Q  Network  Operating  System,  by  Ian  Wade,  that  will  be  published  late 
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in  1991(21).  Currently  a  complete  copy  of  the  NOS  manual  is  distributed 
with  the  package  in  the  form  of  a  computer  file.  It  is  also  available  from  the 
DDN  host  ucsd.edu  in  various  document  formats  including  Postscript  and 
nroff/troff. 

All  of  the  TNC  functions  are  available  in  NOS,  however,  they  are  imple¬ 
mented  in  software.  There  are  no  user  generated  parameters  as  far  as  the 
actual  hardware  TNC  is  concerned.  The  user  communicates  with  the  soft¬ 
ware  TNC  using  commands  similar  to  those  used  in  a  hardware  TNC,  with  a 
syntax  change  that  commands  are  preceded  by  ax25.  The  software  commu¬ 
nicates  with  the  hardware  TNC  using  the  Keep-It-Simple-Stupid(7)  (KISS) 
protocol. 

2.2.2  Requirement  (2)  The  network  routing  algorithm  should  provide  a  route 
for  transmission  of  messages  even  when  there  is  not  a  direct  route  available  between 
source  and  destination. 

AFITPAC  -  The  “digipeat”  option  of  the  TNC  provides  this  function  directly  to  the 
system.  The  operator  can  limit  who  is  allowed  to  use  the  repeat  via  the 
DFROM  command  of  the  PK-232  which  can  be  set  in  the  START.TXT  file 
that  loads  when  initializing  the  system(15). 

NOS  -  The  NOS  package  provides  three  distinct  routing  algorithms  enabling  deliv¬ 
ery  of  messages  to  PRUs  other  than  the  nearest  neighbors^.  They  are  the 
AX. 25  digital  repeating.  Routing  Information  Protocol^  (RIP),  and  Radio 
Shortest  Path  First  Protocol  (RSPF).  NOS  uses  the  AX.25  syntax  con¬ 
nect  interface  NODEl  via  REPEATERl  REPEATER2  to  establish 
a  connection  to  NODEl.  The  interface  argument  is  used  to  specify  which 
hardware  interface  is  to  be  used  in  establishing  the  connection.  NOS  allows 

'The  term  nearest  neighbor  refers  to  those  PRUs  who  are  accessible  without  passing  through 
any  repeaters 

^Information  can  be  found  in  RFCs  iijt  1058 
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for  multiple  connections  to  be  active  simultaneously  on  different  interfaces. 
NOS  also  adds  this  route  to  the  AX.25  routing  table  automatically(21). 

RIP  is  the  same  protocol  utilized  on  the  DDN  which  allows  for  the  applica¬ 
tions  such  as  Simple  Mail  Transfer  Protocol^  (SMTP),  File  Transfer  Protocol 
(FTP),  Post  Office  Protocol^  (POP2),  telnet,  and  rlogin.  It  automatically 
updates  the  Address  Resolution  Protocol  (ARP)  tables,  and  makes  it  pos¬ 
sible  to  monitor  the  RIP  activity  by  using  the  RIP  trace  level  command. 
This  will  display  three  levels  of  RIP  activity  at  the  local  PRU;  level  1  -  only 
RIP  packets  causing  changes  in  the  routing  table  are  displayed,  level  2  -  all 
RIP  packets  are  displayed,  level  0  -  disables  RIP  tracing. 

In  RSPF  protocol,  each  PRU  determines  which  other  PRUs  are  its  neighbors 
by  listening  for  a  special  message  sent  out  by  other  PRUs  running  RSPF. 
When  a  PRU  hears  this  Router- to- Router-Hello  (RRH)  message  it  deter¬ 
mines  whether  the  link  is  bidirectional  by  pinging  the  other  station.  The 
quality  of  the  AX.25  link  is  determined  by  comparing  the  number  of  sent 
and  received  frames  on  the  channel  from  the  particular  node.  The  routing 
table  not  only  contains  a  list  of  the  local  PRU’s  neighbors,  but  a  list  of  all 
the  other  PRUs’  neighbors  as  well(21).  The  size  of  this  table  is  limited  by 
setting  the  horizon,  in  terms  of  hops.  For  example,  if  the  horizon  was  set 
to  2  hops,  the  routing  table  would  contain  only  information  about  the  local 
PRU’s  neighbors  and  their  immediate  neighbors. 

2.2.3  Requirement  (3)  Messages  will  be  encrypted  for  transmission. 

AFITPAC  -  Files  are  encrypted  by  the  GILLAROO  and  can  either  be  saved  on  disk 
for  later  transmission  or,  via  the  secure  link  option,  be  directly  sent  to  the 
distant  station  for  immediate  reception  and  decryption(15). 

^Information  can  be  found  in  RFCs  788,  821,  1090 

^Information  can  be  found  in  RFCs  #  918,  937,  1081,  1082,  1225 
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NOS  - 


ASCII  text  files  can  be  sent  in  NOS  using  Simple  Mail  Transfer  Protocol® 
(SMTP)  and  both  binary  and  text  files  can  be  sent  using  File  Transfer  Pro¬ 
tocol  (FTP). 

This  would  allow  a  file  encrypted  by  the  GILLAROO  and  saved  to  disk  to 
be  transmitted  using  either  SMTP  or  FTP. 

NOS  provides  the  functions  uuencode  and  uudecode  found  in  the  Transmis¬ 
sion  Control  Protocol  (TCP)\Internet  Protocol  (IP)  environment.  Uuencode 
takes  a  binary  file  and  encodes  into  an  ASCII  text  files  so  that  it  may  be 
sent  by  SMTP.  When  the  file  is  received,  it  can  be  run  through  uudecode 
to  obtain  the  original  binary  file.  A  common  practice  on  the  DDN  is  to  use 
SMTP  to  transfer  large  binary  files,  i.  e.  executables  or  images.  They  can 
be  encoded  to  ASCII,  then  split  into  a  number  of  smaller  files,  and  sent  in 
a  mail  message.  At  the  receiver  the  messages  are  saved  to  system  files,  the 
files  are  edited  to  remove  all  of  the  mail  header  information,  and  then  the 
files  are  concatenated,  in  appropriate  order,  to  form  the  original  encoded  file. 
The  file  is  the  run  through  uudecode  to  obtain  the  original  binary  file. 

2.2.4  Requirement  (4)  The  system  will  provide  archival  storage  of  messages 
that  are  transmitted  or  received. 

AFITPAC  -  Transmitted  messages  are  saved  on  computer  disk  at  the  receiving  end 
by  either  the  file  capture  option  or  the  automatic  file  save  function  of  the 
program  (note  that  this  does  not  operate  in  the  Secure  link  mode)(15). 

NOS  -  If  a  NOS  PRU  is  running  and  the  Simple  Mail  Transfer  Protocol®  (SMTP) 
then  any  messages  sent  to  the  users  of  the  PRU  will  automatically  be  placed 
in  their  mailbox.  The  mailbox  is  nothing  more  than  a  designated  directory 
for  each  user  of  the  system.  The  next  time  the  user  connects  to  this  PRU’s 
bulletin  board,  they  will  be  notified  there  is  mail  waiting  for  them.  They 

^Information  can  be  found  in  RFCs  #  788,  821,  1090 
^Information  can  be  found  in  RFCs  #  788,  821,  1090 
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can  read  the  message,  delete  the  message,  reply  to  the  message,  forward 
the  message,  or  save  the  message  to  another  file.  If  the  destination  NOS 
PRU  is  not  running,  then  SMTP  will  send  a  message  back  to  the  originator 
informing  him  that  the  message  was  undeliverable  and  may  offer  a  possible 
explanation. 

NOS  also  provides  the  Post  Office  Protocol^  (POP2)  application  intended 
for  use  in  networks  where  hosts  are  normally  off  when  not  in  use(21).  POP2 
allows  mail  to  be  collected  at  a  mailserver  which  is  always  on  so,  when  a  client 
PRU  powers  on,  it  will  request  mail  from  the  mailserver.  The  client  receives 
all  of  the  mail  destined  for  it  and  then  distributes  it  to  its  users’  mailboxes. 
This  type  of  mail  delivery  avoids  the  problem  of  SMTP  not  being  able  to 
deliver  mail  to  PRUs  that  are  down. 

2.2.5  Requirements  (5),  (6),  &  (7)  (5)  The  system  should  provide  a  trans¬ 
mit  message  queue  so  that  multiple  messages  can  be  transmitted  with  little  operator 
intervention.  The  queue  should  be  able  to  hold  at  least  twenty  messages.  (6)  Queued 
messages  that  are  not  able  to  be  transmitted  will  be  flagged  for  the  operators  atten¬ 
tion.  (7)  The  system  should  provide  for  reception  messages  whether  the  position  is 
attended  or  not. 

AFITPAC  -  (5)  -  A  transmit  Queue  of  20  files  is  presently  in  the  system.  A  larger 
queue  can  be  created  by  changing  the  TQ-MAX  in  the  TXFILE.C  module 
and  recompiling  the  entire  program(15).  (6)  -  Files  that  can  not  be  trans¬ 
mitted  will  cause  the  system  to  stop  the  transfer  and  alert  the  operator  by 
sounding  the  beep  at  the  computer.  The  operator  can  then  continue  sending 
the  remaining  file  in  the  queue  simply  by  pressing  the  start  TX  key  (F3) 
again(15).  (7)  If  a  station  is  unattended,  files  will  automatically  capture 
via  the  automatic  file  save  function  built  into  the  transmit  and  receive  mod¬ 
ules  of  the  program.  The  receive  module  examines  every  character  received 

^Information  can  be  found  in  RFCs  #  918,  937,  1081,  1082,  1225 
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and  if,  it  is  one  of  the  special  function  control  codes  (CTRL-E,  CTRL-J,  or 
CTRL-Q),  other  actions  are  initiated  such  as  auto-file  save  or  the  remote 
“station  heard”  command(15). 

NOS  -  If  the  Simple  Mail  Transfer  Protocol®  (SMTP)  feature  of  NOS  is  used, 

then  the  only  limitation  to  the  number  of  files  that  a  can  be  queued  for 
transmission  is  the  amount  of  free  disk  space.  SMTP  uses  the  directory 
N;\NET\SPOOL\MQUEUE  to  store  messages  waiting  for  transmission. 
The  advantage  to  this  method  is  if  a  PRU  goes  down  during  transmission, 
the  contents  of  the  message  and  of  the  outbound  queue  are  not  lost.  When 
the  PRU  comes  back  up,  it  can  resume  transmission  of  all  unsent  messages 
without  user  intervention. 

If  the  File  Transfer  Protocol  (FTP)  feature  of  NOS  is  used;  there  is  effec¬ 
tively  no  limitation  on  the  number  of  files  that  can  be  queued  for  transmis¬ 
sion.  Queuing  can  be  accomplished  by  using  the  FTP  commands,  mput  and 
mget.  However,  the  method  is  vulnerable  to  PRUs  going  down,  meaning 
that  if  transmission  is  aborted,  the  user  must  reissue  the  request. 

2.2.6  Requirement  (10)  A  converse  mode  should  be  provided  to  allow  inter¬ 
active  communication  between  two  node  operators. 

AFITPAC  -  Operators  can  converse  directly  with  each  other  just  by  connecting  with 
another  station  and  then  typing  on  screen.  When  the  operator  hits  the  return 
key  all  of  the  typed  data  will  be  sent  out  ais  a  packet(15). 

NOS  -  NOS  provides  two  methods  for  conversations  between  stations;  1)  through 
the  normal  procedure  of  establishing  a  AX. 25  connection  between  the  two 
stations  2)  through  the  Chat  command  available  in  the  bulletin  board  sys¬ 
tem.  In  both  cases,  whatever  is  typed  on  the  screen  is  transmitted  to  the 
other  PRU  when  a  carriage  return  is  entered. 

^Information  can  be  found  in  RFCs  #  788,  821,  1090 
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The  Chat  function  is  similar  to  the  PHONE  application  available  on  VAX/VMS 
systems  and  the  TALK  application  on  Unix  systems.  Except  Chat  mode  is 
a  direct  line  to  the  system  operator  whose  bulletin  board  the  user  is  logged 
into.  When  a  user  selects  Chat,  the  system  notifies  the  operator  of  the 
request.  If  he  is  available  he  can  converse  with  the  user  requesting  to  Chat. 

2.2.1  Requirement  (II)  A  direct  connection  capability  between  the  TNC  and 
the  GILLAROO,  via  the  packet  radio  system  computer,  should  be  incorporated  into 
the  system  software  to  allow  for  a  secure  converse  mode  for  the  system. 

AFITPAC  -  For  packet  computers  with  2  serial  ports  and  equipment  set  up  as  in  con¬ 
figuration  I,  the  operators  can  converse  securely.  The  operator  sets  up  a 
connection  and  both  ends  go  into  the  secure  link  mode.  All  data  typed  in 
at  the  TEMPEST  computer  is  then  encrypted  by  the  GILLAROO,  passed 
through  the  packet  computer  to  the  PK-232.  When  the  buffer  is  full  (128 
bytes  of  user  typed  data)  or  when  the  return  on  the  packet  computer  key¬ 
board  is  pressed,  a  packet  will  be  sent  to  the  other  station  where  it  will  be 
decrypted  and  displayed  on  the  TEMPEST  computer  screen. 

NOS  The  function  of  requirement  ( 1 1)  is  not  native  tc  the  NOS  package.  However, 

further  examination  and  modification  of  the  Point-to- Point  Protocol®  (PPP) 
could  provide  this  capability.  PPP  allows  for  network  connections  to  be  made 
over  serial  lines  and  this  could  be  exploited  to  create  the  required  service. 

2.2.8  Requirement  (12)  ,4  system  operator  handbook  will  be  provided.  It  will 
include  system  wiring  diagrams  and  a  software  user's  guide. 

AFITPAC  -  The  adequacy  of  the  documentation  will  be  determined  by  the  thesis  spon¬ 
sor  upon  completion  of  this  thesis(15). 

^Information  can  be  found  in  RFCs  #  1134.  1171,  1172.  1220 


2-10 


NOS  -  The  NOS  documentation  is  a  living  document,  which  is  continually  updated 

3US  new  features  are  added.  Since  the  source  code  for  all  functions  is  provided, 
and  the  software  is  free  to  the  public,  a  myriad  of  authors  have  written  code 
and  documentation.  Ian  Wade’s  book(21)  is  the  first  published  attempt  at 
formalizing  the  documentation.  All  of  the  documentation  is  available  from 
a  user’s  manual  computer  file,  distributed  with  the  software. 

2.3  Commentary  on  Comparison 

T^ble  2.1  provides  a  summary  of  how  NOS  compares  to  the  AFLC  require¬ 
ments.  There  are  three  requirements,  (3),  (8),  and  (11),  that  NOS  does  not  meet 
that  warrant  further  discussion.  Since  the  C  source  code  is  available,  modifications 
could  be  made  to  the  NOS  package  to  bring  it  more  in  line  with  the  AFLC  re¬ 
quirements.  In  regards  to  meeting  requirement  (3),  there  are  two  ways:  1)  save 
the  GILLAROO  encryption  devices  output  to  a  disk  file  and  transmit  the  file  using 
either  File  Transfer  Protocol  (FTP)  or  Simple  Mail  Transfer  Protocol’®  (SMTP)  2) 
create  a  software  module  that  would  encrypt  the  message  files  and  add  it  to  the  NOS 
package.  This  second  solution  would  also  allow  NOS  to  meet  requirement  (11),  the 
keyboard  input  could  be  piped  through  the  encryption  module  before  transmission. 
As  for  requirement  (8),  the  command  line  prompt  could  be  replaced  with  a  menu 
system.  Using  today’s  C  programming  tools  for  window  environments  an  interface 
could  be  created  to  take  advantage  of  NOS’s  multiple  session  capability  and  provide 
the  menu  driven  interface. 

There  are  other  factors  that  should  also  be  considered  in  this  comparison. 
First,  AFITPAC  is  limited  to  the  area  that  can  be  covered  by  the  packet  radio  net¬ 
work  that  it  supports.  AFITPAC  nodes  that  become  isolated  due  to  problems  with 
radio  transmission  have  no  other  recourse  than  to  hope  that  broadcasting  conditions 
improve.  NOS  nodes  have  the  option  of  using  DDN  to  ’’wormhole’’  the  transmission 

'’’Information  can  be  found  in  RFC's  ^  788,  821.  1090 
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Req. 

# 

Meets 

Req. 

Does 

Not 

Meet 

Req. 

Comments 

(1) 

X 

The  bulletin  board  system  is  relatively  easy 

(8) 

X 

X 

to  use.  It  is  menu  driven  using  single 

(9) 

X 

letter  commands.  Help  is  available  for  each 
command  typing  Help  command. 

The  command  prompt  interface  is  slightly  more 
difficult  to  use.  However,  experienced  DDN 
users  will  find  it  a  familiar  interface. 

Three  levels  of  help  are  available: 

1.  Typing  help  or  f  lists 
the  commands  accessible. 

2.  Typing  the  command  followed  by  a  f 
lists  the  parameters  acceptable  for  the 
command. 

3.  Using  NOSVIEW  to  read  the  detailed 
documentation  for  each  command. 

(2) 

X 

Three  routing  methods  are  provided: 

1.  RIP 

2.  RSPF 

3.  AX. 25  digital  repeating 

(3) 

X 

NOS  does  not  provide  any  data  encryption  services. 

X 

IHII 

NOS  provides  SMTP  services  which  do  not  require 

X 

operator  intervention  to  transmit  and  receive 

X 

1 

messages.  SMTP  uses  disk  directories  for  its 
transmit  and  receive  queues,  allowing  for  queue  sizes 
as  large  as  the  disk  space  will  support. 

If  a  message  is  unable  to  be  delivered  SMTP  returns 
a  message  to  the  originator  indicating  the  problem. 

This  message  is  treated  just  like  any  other  piece  of 
mail  and  will  exist  until  the  originator  deletes  it. 

(10) 

X 

Converse  mode  is  provide  by  two  means: 

1.  AX.25  connections 

2.  Chat  command  on  the  bulletin  board  system. 

(11) 

X 

NOS  does  not  provide  a  transparent  link  from 
another  serial  that  would  allow  the  TEMPEST 
machine  with  the  GILLAROO  card  to  use  the  PRNET. 

(12) 

X 

Comparing  the  AFITPAC  documentation  with  the 

NOS  documentation,  NOS  meets  the  users  requirements. 

Table  2.1.  Summary  of  how  NOS  compares  to  AFLC  Requirements 
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of  AX.25  packets  encapsulated  in  Internet  Protocol  (IP)  packets(21).  The  protocol 
used  for  this  is  declared  in  RFC1226.  This  would  allow  groups  of  NOS  packet  radio 
networks  to  be  Unked  via  DDN  cabhng.  The  procedure  in  NOS  for  making  this  type 
of  connection  is  connect  destination  via  locaLaxip.call  remote-ax25.call,  which  is 
the  same  as  aui  AX.25  connection  made  via  digipeaters.  Wormholing  AX.25  over 
DDN  or  similar  networks  dramatically  increases  the  range  of  the  NOS  packet  radio 
networks. 

Second,  both  packages  supply  complete  C  source  code  hstings.  Since  AFITPAC 
is  a  much  smaller  package,  there  is  less  code  to  understand  before  making  modifica¬ 
tions.  NOS  has  many  modules  written  by  scores  of  authors.  The  version  of  the  source 
code  obtain  for  this  project  has  approximately  270  program  files,  header  files,  and 
hbraries.  These  factors  cause  a  problem  for  anyone  who  needs  to  make  modifications 
to  the  package  as  Lebano  found(14). 


The  design  and  implementation  of  the  DES  [Data  Encryption  Stan¬ 
dard]  Enhanced  KA9Q  [NOS]  Internet  package  was  an  evolutionary  pro¬ 
cess.  this  research  project  was  undertaken  with  a  minimal  understanding 
of  the  TCP/IP  protocols  Jind  no  knowledge  of  packet  radios  and  the  C 
programming  language.  In  addition,  the  KA9Q  [NOS]  package,  although 
very  well  structured,  did  not  have  any  true  design  documentation  other 
than  a  user’s  manual  and  had  hmited  documentation  in  the  source  code. 
This  presented  a  learning  curve  which  had  to  be  overcome  before  design 
modifications  could  be  achieved. (14) 


Third,  AFITPAC  is  the  property  of  the  United  States  Air  Force,  allowing  for 
the  unfettered  distribution  and  modification  of  the  software.  NOS  is  currently  free 
for  distribution  to  the  public  for  non-commercial  use.  However,  all  portions  of  the 
package  are  copyrighted  by  the  authors.  This  means  that  the  Air  Force’s  use  and 
modification  of  the  NOS  software  is  best  determined  by  the  lawyers. 
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2.^  Summary 

If  there  are  no  legal  barriers  to  using  the  Network  Operating  System,  NOS, 
then  this  should  be  the  package  of  choice.  It  satisfies  the  AFLC  requirements  and 
in  those  areas  that  it  falls  short,  it  was  shown  how  NOS  could  be  modified  to  meet 
them.  NOS  provides  the  services  spelled  out  in  five  Department  of  Defense  (DOD) 
Military  Standard  Protocols:  1)  MIL-STD-1777  Internet  Protocol  (IP),  2)  MIL- 
STD-1778  Transmission  Control  Protocol  (TCP),  3)  MIL-STD-1780  File  Transfer 
Protocol  (FTP),  4)  MIL-STD-1781  Simple  Mail  TTansfer  Protocol  (SMTP),  and  5) 
MIL-STD-1782  TELNET  Protocol(17).  These  standards  are  used  throughout  all 
DOD  organizations.  Therefore,  the  use  of  NOS  could  be  widely  accepted  because  of 
its  familiarity  to  computer  network  users  DOD  wide. 

Finally,  NOS  provides  many  applications  to  its  users,  allows  them  to  have  mul¬ 
tiple  concurrent  sessions,  and  has  many  services  that  run  unattended.  An  active  NOS 
node  could  easily  generate  a  tremendous  amount  of  network  traffic.  An  AFITPAC 
node  however,  only  allows  for  one  session  to  be  running  at  a  time.  While  a  node 
is  transferring  a  file  the  operator  cannot  connect  to  another  node.  Also  AFITPAC 
hats  only  one  service  that  runs  unattended,  which  is  Geier’s  routing  algorithm.  The 
file  capture  routine  of  AFITPAC  can  receive  files  while  the  station  is  unattended, 
but  someone  must  initiate  the  transmission  and  once  the  transmission  is  complete 
the  function  terminates.  Both  Geier’s  routing  algorithm  and  the  NOS  unattended 
services  can  be  influenced  by  the  operators,  but  they  run  continuously  while  the  node 
is  active.  Consequently,  a  comparison  has  to  be  made  between  NOS  and  AFITPAC 
to  determine  which  yields  better  channel  usage  for  the  amount  of  services  provided. 
Is  the  fact  that  NOS  provides  all  of  these  services  outweighed  by  a  saturated  packet 
radio  network  because  of  them?  Does  AFITPAC  poorly  use  the  available  channel 
capacity  or  provide  such  limited  services  that  it  does  not  meet  user’s  needs?  The 
answer  to  these  questions  lies  in  the  task  about  to  be  undertaken:  the  design  of  a 
simulation  to  analyze  the  performance  of  packet  radio  network  programs. 
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III.  Discussion  of  Model  Design  and  Methodology 


S.  1  Introduction 

This  chapter  begins  with  a  discussion  of  modularity  and  how  it  relates  to  both 
computer  communications  networks  and  simulations.  Dr.  Bernard  Zeigler’s  concepts 
of  modules  with  ports  which  communicate  via  messages  are  introduced (22).  The 
messages  are  generated  by  both  external  and  internal  events  and  the  components 
are  responsible  for  processing  the  messages.  Then  by  examining  the  physical  and 
data  hnk  layers  in  the  Open  System  Interconnection  (OSI)  network  model,  as  they 
pertain  to  a  PRNET,  a  design  for  a  packet  radio  network  simulator  is  derived.  The 
development  of  simulation  modules  to  mimic  the  layers  above  the  data  link  layer  are 
not  necessary  because  these  are  the  functions  being  analyzed. 

3.2  Model  Design  Techniques 

Any  discussion  that  involves  computer  communications  networks  and  simula¬ 
tions  begins  with  the  topic  of  modularity.  Modularity  is  defined  as  “the  ability  of  a 
system  to  be  expanded  to  [be]  changed  with  minimal  difficulty.  (6)”  For  the  purposes 
of  this  discussion,  modularity  takes  this  definition  one  step  further  saying  that  it 
is  achieved  by  using  discrete  components  or  modules.  Zeigler  discusses  some  of  the 
benefits  and  characteristics  of  a  simulation  designed  using  discrete  components(22). 
There  are  two  significant  points  made  in  the  article.  First,  a  component  possesses 
input  and  output  ports  through  which  it  interacts  with  its  environment.  In  the 
discrete-event  case,  the  events  determine  what  values  will  appear  on  these  ports. 
The  external  events  cause  activity  on  the  input  ports  of  these  components,  which 
then  respond  to  this  activity.  During  the  response  the  component  may  change  its 
state  causing  internal  events,  which  may  cause  activity  on  the  output  ports.  Second, 
a  benefit  of  modular  construction  is  that  components  can  be  independently  tested. 
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The  ability  to  do  such  testing  at  each  stage  of  development  improves  the  reliability 
and  efficiency  of  the  hnal  simulation  model.(22) 

The  ideal  of  modularity  motivated  the  International  Standards  Organization 
(ISO)  in  1984  to  adopt  its  seven  layer  model  for  computer  communications  networks(18). 


The  communications  functions  are  partitioned  into  a  vertical  set  of 
layers.  Each  layer  performs  a  related  subset  of  the  functions  required 
to  communicate  with  another  system.  It  relies  on  the  next  lower  layer 
to  perform  more  primitive  functions  and  to  conceal  the  details  of  those 
functions.  It  provides  services  to  the  next  higher  layer.  Ideally,  the  layers 
should  be  defined  so  that  changes  in  one  layer  do  not  require  changes  in 
the  other  layers(18). 

-  Stallings 


This  is  the  reference  model  used  to  define  standards  for  linking  heterogenous  com¬ 
puter  systems. 

Each  layer  in  this  communications  model  can  be  thought  of  as  a  discrete  sub¬ 
component.  All  that  each  subcomponent  needs  to  know  are:  the  services  provided 
by  the  other  subcomponents,  and  which  port  should  send  messages  to  obtain  such 
services.  For  the  purpose  of  this  discussion,  we  are  mainly  interested  in  the  first  four 
layers  of  the  model  in  Table  3.1(18),  namely  physical,  data  link,  network,  and  trans¬ 
port.  These  will  be  used  to  explain  the  OSI  terminology.  The  OSI  model  calls  the 
ports  of  each  layer  service  access  points  (SAPs)(18,  19).  The  transport  layer  sends 
a  service  request  to  the  network  layer  across  their  common  interface  at  the  SAP. 
The  service  request  is  in  the  form  of  an  Interface  Data  Unit  (IDU).  The  IDU  con¬ 
sists  of  a  Service  Data  Unit  (SDU)  and  Interface  Control  Information  (ICI)(18,  19). 
The  network  layer  examines  the  contents  of  the  ICI  to  determine  the  exact  t3rpe  of 
services  requested.  The  network  layer  will  determine  the  length  of  the  SDU  from 
the  transport  layer,  and  fragment  it,  as  necessary.  Then  each  fragment  receives  its 
own  network  layer  header  to  form  a  Protocol  Data  Unit  (PDU).  The  network  layer 
makes  a  service  request  to  the  data  link  layer  via  a  SAP.  The  network  layer  will  pass 
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Layer  Name 

Description 

1.  Physical 

Concerns  the  transmission  of  unstructured  bit  stream 
over  physical  medium;  deals  vdth  the  mechanical, 
electrical,  functional,  and  procedural  characteristics 
to  access  the  medium. 

2.  Data  Link 

Provides  for  the  reliable  transfer  of  information 
across  the  physical  link;  sends  blocks  of  data 
(frames)  with  the  necessary  synchronization,  error 
control,  and  flow  control. 

3.  Network 

Provides  upper  layers  with  independence  from  the  data 
transmission  and  switching  technologies  used  to  connect 
systems;  responsible  for  establishing,  maintaining,  and 
terminating  connections. 

4.  Ikansport 

Provides  reliable,  transparent  transfer  of  data  between 
end  points;  provides  end-to-end  error  recovery  and  flow 
control. 

5.  Session 

Provides  the  control  structure  for  communication  between 
applications;  establishes,  manages,  and  terminates 
connections  (sessions)  between  cooperating  applications. 

6.  Presentation 

Provide  independence  to  the  apphcation  processes  from 
differences  in  data  representation  (syntax). 

7.  Application 

Provides  access  to  the  OSI  environment  for  users  and 
also  provides  distributed  information  services. 

Tkble  3.1.  The  OSI  Layers 


its  PDU  as  an  SDU  to  the  data  link  layer  along  with  some  ICI.  See  Figure  3.1  for 
clarification. 

Note  that  on  the  receiving  end  of  the  communications  network,  each  layer 
receives  a  PDU  from  its  peer  layer  at  the  transmitting  end.  The  network  layer  would 
have  received  all  of  the  PDUs  from  the  transmitting  network  layer  and  recombined 
them,  as  necessary,  into  a  PDU  for  its  transport  layer.  The  receiver’s  transport  layer 
would  be  signaled  by  the  receiver’s  network  layer  that  data  wais  available  for  it  at 
the  SAP.  The  transport  layer  would  then  process  the  PDUs  and  pass  a  PDU  up  to 
the  session  layer  in  a  similar  fashion. 

The  transport  layer’s  service  request  is  viewed  as  an  external  event  by  the 
network  layer.  This  event  places  data  (SDU)  on  an  input  poit  (SAP).  The  network 
layer  processes  the  SDU  and  if  the  ICI  causes  internal  events,  the  network  layer 
makes  a  service  request  of  the  data  hnk  layer.  The  similarity  between  the  OSI 
layers  passing  of  SDUs  and  Zeigler’s  discussion  of  passing  messages  between  discrete 
components  motivates  the  modular  design  for  the  Packet  Radio  Network  simulation. 
The  most  difficult  task  in  the  design  process  was  determining  which  components  to 
model  and  the  level  of  abstraction  needed.  The  problems  encountered  during  the 
design  process  and  the  attempted  programming  will  be  discussed  in  the  Chapter  IV. 
The  design  solution  chosen  is  the  next  topic  of  discussion. 

3.3  Overview  of  the  Design 

As  discussed  previously,  a  packet  radio  network  consists  of  a  group  of  Packet 
Radio  Units  (PRUs).  Elach  PRU  consists  of  a  computer,  a  Terminal  Node  Controller 
(TNC),  and  a  transceiver.  The  computer  may  be  of  any  brand  name  and  running 
any  operating  system  as  long  as  it  has  some  way  to  communicate  with  the  TNC. 
The  TNC  may  be  from  various  vendors  and  can  support  different  protocols.  The 
broadcast  radio  may  be  from  any  vendor  and  support  various  frequencies.  The 
diversity  of  products  makes  it  necessary  to  construct  a  simulation  model  based  on 
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Transmitter  Receiver 


Figure  3.1.  Figure  Illustrating  PDU,  SDU,  and  ICI  Passing. 
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behavioral  implementations  of  the  components.  For  the  purpose  of  this  thesis,  the 
collection  of  all  of  these  components  will  be  called  a  Node. 

The  simulation  design  consists  of  multiple  Nodes  passing  messages  to  each  other 
through  another  component  called  a  Channel.  The  Channel  will  take  the  messages 
from  the  Nodes  and  distribute  them  to  the  other  Nodes  in  the  simulated  network. 
As  the  simulation  progresses,  data  about  the  message  traffic  will  be  collected  by  a 
Monitor.  The  data  collected  will  be  analyzed  upon  completion  of  the  simulation. 

3.4  The  Channel 

The  logical  place  to  start  is  the  bottom  at  OSI  layer  one,  the  physical  layer.  In 
the  specific  case  of  a  packet  radio  network,  the  physical  layer  deals  with  radios  and 
the  physical  transmission  medium,  the  free  space.  The  module  used  to  model  this 
layer  is  referred  to  as  the  Channel.  The  Channel  provides  only  one  service  which 
is  broadcasting  of  frames  between  Nodes.  The  Channel  must  know  which  nodes  can 
hear  other  nodes,  and  this  information  is  provided  by  the  Connectivity  Matrix.  The 
two  dimensional  Connectivity  Matrix  is  indexed  by  node  identifiers.  Node  identifiers 
could  be  unique  alphanumerics,  as  in  Figure  3.2  or  callsigns  e.  g.  AF8EN,  AF8LS, 
WPA4B  .  Ekich  element  would  be  a  “1”,  (source  can  hear  destination),  or  a  “0”, 
(source  can  not  hear  destination). 
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Figure  3.2.  Connectivity  Matrix 


In  this  example  of  the  Connectivity  Matrix,  Figure  3.2,  node  A  can  hear  itself 
and  node  C,  but  can  not  hear  nodes  B  and  D.  This  matrix  holds  the  network’s 
topology.  Some  might  argue  that  this  makes  the  Channel  too  smart  since  it  should 
only  be  responsible  for  the  transmission  of  frames  to  nodes.  Perhaps  this  information 
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should  be  kept  by  the  simulation  manager  or  the  nodes.  However,  by  examining  a 
network  which  uses  cabling  to  connect  its  nodes,  it  becomes  obvious  that  it  is  the 
physical  connections  that  determine  the  network’s  topology.  Thus  the  Channel  is 
the  appropriate  place  for  this  information. 

The  frame  is  the  basic  unit  sent  over  the  transmission  medium  and  the  Channel 
must  know  its  source  in  order  to  route  it  properly.  Therefore,  the  frame  must  contain 
a  field,  l^ansmit-Source,  which  holds  the  node  identification  of  the  transmitter. 
When  the  Channel  receives  a  request  to  broadcast  a  frame,  it  will  examine  the 
Transmit-Source  field,  find  the  appropriate  row  of  the  Connectivity  Matrix,  and 
pass  a  copy  of  the  frame  to  all  the  nodes  (except  the  source)  that  can  hear  it. 

For  example.  Node  C  has  a  packet  to  send  to  Node  D,  see  Figure  3.3.  Node  C 
sets  the  Tiransmit .Source  field  of  the  frame  to  “C”  and  places  the  packet  in  the 
frames  data  field.  Node  C  requests  the  Channel  to  broadcast  the  frame,  passes 
the  frame  to  the  Channel.  The  Channel  examines  the  Transnut  .Source  field  and 
finds  “C”  is  the  source.  The  Channel  looks  through  the  transmitter  index  of  the 
Connectivity  Matrix,  Figure  3.2.  When  it  finds  the  row  corresponding  to  “C”  as  the 
transmitter,  it  indexes  through  the  receivers  to  see  which  Nodes  can  hear  Node  C.  It 
then  makes  a  copy  of  the  frame  for  each  of  these  Nodes,  Nodes  A  and  D.  A  copy  is  not 
made  for  Node  C  because  a  Node  can  not  receive  frames  while  it  is  transmitting.  It 
is  necessary  to  make  copies  of  the  frame  instead  of  passing  it  by  reference  to  the 
nodes,  otherwise  they  all  would  be  modifying  the  same  frame. 

This  method  of  passing  frames  using  the  Connectivity  Matrix  imphes  that  the 
Channel  has  no  propagation  delay  and  is  error  free.  Unfortunately,  neither  of  these 
is  a  realistic  assumption.  There  is  a  significant  amount  of  time  spent  in  transmitting 
and  receiving  a  frame  since  we  are  working  with  radio  data  rates  of  300  or  1200 
baud.  Furthermore,  if  the  distance  between  two  connected  nodes  is  large  enough, 
there  will  be  a  delay  introduced  by  radio  wave  propagation  through  the  free  space. 
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Figure  3.3.  Ebcample  of  Nodes  passing  a  frame  through  the  Channel,  broadcasting 
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For  the  purposes  of  this  thesis  the  time  spent  transmitting  and  receiving  plus  the 
propagation  delay  will  be  referred  to  as  the  delivery  delay. 


FVame  Size  in  Bits 

Radio  Data  Rate  (Baud) 

152  (Minimum) 

2656  (Maximum) 

300 

0.506  seconds 

8.85  seconds 

1200 

0.126  seconds 

2.213  seconds 

Table  3.2.  Limits  on  Packet  Ikansmission  Delays 


The  transmission  delays  shown  in  Table  3.2  are  large  compared  to  the  delays 
caused  by  radio  wave  propagation  between  nodes.  Therefore  the  delivery  delay  need 
only  consider  the  transmission  delays.  However,  if  the  data  rates  increase  to  9600 
baud  and  possibly  56000  baud,  the  transmission  delay  will  reach  the  same  magnitude 
as  the  propagation  delay  and  thus  the  delivery  delay  would  need  to  consider  both. 

Assuming  that  propagation  delay  is  negligible  means  that  the  moment  a  node 
begins  transmitting  another  node  begins  receiving.  Then  the  transmission  delay 
needs  to  be  counted  only  once  and  can  be  simply  realized  at  the  delivery  stage  of 
the  Channel.  At  this  point,  the  frame  definition  must  go  through  another  iteration, 
adding  on  a  field  containing  its  length,  fVame-Length.  The  Channel  would  examine 
this  field  prior  to  passing  the  frame  to  the  destination  Node  to  determine  the  appro¬ 
priate  delivery  delay.  It  would  schedule  the  passing  of  the  frame  to  the  Node  at  the 
appropriate  simulation  time.  By  placing  this  delay  in  the  Channel,  the  propagation 
delay  can  be  included  in  the  dehvery  delay  calculation,  if  it  becomes  necessary. 

The  other  assumption  was  the  Channel  was  error  free.  To  correct  this  erroneous 
assumption,  the  concept  of  the  Probabihty  of  Bit  Error  (Pf,)  Matrix  is  introduced 
(please  see  Figure  3.4).  The  p,  Matrix  is  similar  in  construction  to  the  Connectiv¬ 
ity  Matrix  except  the  elements  contain  a  Pi,  threshold  for  the  transmitter  receiver 
pair.  The  Pi,  Matrix  works  as  follows:  When  the  Channel  receives  a  frame  for  broad¬ 
casting  it  reads  the  frames  Erame.Length  and  Transmit -Source  fields,  calculates  the 
probabihty  of  frame  error  for  the  given  frame  length  and  p,  Matrix  entry,  and  then 


3-9 


Xmt.\Recv. 

A 

B 

C 

D 

A 

0 

0 

2.46E-10 

0 

B 

0 

0 

0 

3.67E-15 

C 

2.46E-10 

0 

0 

2.171E-13 

D 

0 

3.67E-15 

2.171E-13 

0 

Figure  3.4.  P*  Matrix 


determines  if  the  frame  is  in  error.  This  is  accomplished  by  using  a  random  ntimber 
generator  with  the  probability  distribution  for  the  t3rpe  of  channel  modeled,  ff  the 
number  returned  when  the  random  number  generator  is  called  exceeds  the  proba¬ 
bility  of  frame  error  then  the  Channel  will  mark  the  frame.  If  only  one  copy  of  the 
frame  is  used  for  all  the  nodes,  then  the  last  calculation  of  frame  error  would  apply 
to  all  the  receiving  nodes.  Therefore,  it  is  necessary  to  make  copies  of  a  frame  for 
each  receiving  Node  during  the  broadcasting  process.  In  order  to  mark  the  frame  as 
being  in  error,  another  field  must  be  added  to  our  definition  of  a  frame.  This  new 
field  will  be  called  FVame.Error  and  can  use  a  simple  toggle  switch  to  indicate  error 
or  no  error. 

There  are  other  control  items  that  need  to  be  addressed  concerning  the  interface 
between  the  Channel  and  Node  modules.  The  first  is  that  of  carrier  sensing.  In  the 
current  scheme  of  packet  radio,  each  node  listens  before  it  transmits.  If  the  node  does 
not  hear  anything,  it  transmits.  The  Channel  must  be  able  to  let  each  Node  know  if 
another  Node  that  it  can  hear  is  transmitting.  This  is  accomplished  by  telling  each 
node  that  can  hear  a  particular  frame  transmission  to  set  a  carrier  flag  associated 
with  that  Channel.  At  the  instant  when  the  frame  is  received  by  the  Channel,  it 
sets  a  carrier  flag,  and  makes  a  copy  of  it  for  the  receiving  Node.  The  carrier  flag  is 
cleared  at  the  same  time  the  Channel  is  scheduled  to  deliver  the  frame  to  the  Node. 
The  interaction  between  the  Nodes  and  the  Channel  controls  the  Nodes  access  to 
the  Channel. 

Another  control  item  to  be  addressed  is  that  of  frame  collisions.  H  two  or  more 
nodes  decide  to  transmit  at  exactly  the  same  simulation  time  a  collision  occurs.  Since 
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the  radio  can  not  listen  while  it  is  transmitting,  handhng  a  collision  is  not  as  simple 
as  vdth  an  Ethernet  transceiver,  which  continues  to  hstcn  on  the  cable  while  it  is 
transmitting.  If  it  hears  another  signal  during  its  transmission  a  collision  is  detected, 
transmission  is  terminated,  and  a  special  signal  is  sent  over  the  cable  indicating  a 
coUision.  In  packet  radio,  however,  the  radio  switches  between  transmit  and  receive 
so  the  only  vray  a  colhsion  is  detected  is  by  not  receiving  an  acknowledgement  for  a 
packet.  However,  for  purposes  of  this  project,  the  discrete  event  simulation  frames 
are  delivered  and  received  sequentially  and  instantaneously.  At  the  time  a  frame  is 
scheduled  to  be  delivered  to  a  Node  the  whole  frame  is  sent  at  once  by  the  Channel. 
The  whole  intent  of  introducing  the  dehvery  delay  was  to  simulate  the  real  world 
delay  encountered  in  transmitting  and  receiving.  Yet  striving  for  realism  creates 
another  problem,  the  problem  of  how  to  deal  with  frame  collisions. 

Once  again  the  two-dimensional  matrix  appears  to  be  a  feasible  solution.  The 
Collision  Matrix  could  be  indexed  by  node  identifiers  and  each  element  composed 
of  a  Pramc-Delivery.Pending  flag  and  the  Time.of-Next. Delivery.  Along  with  this 
matrix,  a  CoUision  Array  indexed  by  node  identifiers  is  needed.  Each  element  of  the 
array  requires  a  CoUision-Indicator  flag  and  the  CoUision-End.Time.  Each  element 
of  the  matrix  and  array  is  initiedized  to  zero.  When  a  frame  is  received  from  Node  C. 
by  the  Channel  for  broadcasting,  the  Channel  sets  the  FVame.Delivery-Pending  flag 
and  sets  the  Ti  me  _of_Next- Deli  very  equal  to  the  current  simulation  time  plus  the 
transmission  delay  (Figure  3.5). 

At  the  same  simulation  time  that  the  frame  is  originaUy  processed  by  the  Chan¬ 
nel,  it  examines  the  row  of  the  CoUision  Matrix  that  corresponds  to  the  receiving 
node.  In  this  particular  case  there  are  no  frame  deliveries  pending  for  this  destination 
node  (Figure  3.5).  This  results  in  the  CoUision  Array  looking  hke  Figure  3.6.  When 
the  next  frame  is  transmitted  from  Node  B,  the  Channel  checks  the  Connectivity 
Matrix,  Figure  3.2.  The  Channel  would  copy  the  frame  and  deliver  to  Node  D.  At 
the  same  simulation  time  the  Channel  updates  the  ColUsion  Matrix  a«  in  Figure  3.7. 
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Figure  3.5.  Collision  Matrix  -  transmission  of  frame  from  C 
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Figure  3.6.  Collision  Array 


Once  the  matrix  has  been  updated,  the  Channel  examines  the  entire  column  corre¬ 
sponding  to  the  receiver  to  determine  if  there  are  any  other  frames  pending  delivery. 
This  time  there  is  another  frame  pending  delivery  to  Node  D.  The  Channel  then 
compares  the  two  Pending-Delivery -Times  to  see  which  is  greater,  it  sets  the  Col- 
Usion-Ehid-Time  equal  to  the  greater  time,  and  sets  the  Collision-Indicator  in  the 
Collision  Array.  This  results  in  a  Collision  Array  hke  Figure  3.8. 

When  the  simulation  time  comes  to  deliver  the  pending  frames,  the  Channel 
should  check  the  Collision  Array.  If  the  Collision-Indicator  is  set,  it  should  compare 
the  Collision-£hid-Time  with  the  current  simulation  time,  the  current  simulation 
time  is  less  than  the  Collision-Ehid-Time,  the  Channel  should  discard  the  frame.  If 
the  current  simulation  time  is  greater  than  the  Collision-End-Time,  the  Channel 
should  clear  the  Collision-Indicator,  zero  the  Collision-End-Time,  and  dehver  the 
frame  to  the  receiver.  Once  the  frame  is  delivered,  the  Channel  should  reset  the 
Collision  Matrix  element  corresponding  to  the  transmitter  receiver  pair,  unless  there 
is  another  frame  pending  delivery  from  this  same  pair.  The  Channel  could  tell  if  the 
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Figure  3.7.  Collision  Matrix  -  transmission  of  frame  from  B 
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Figure  3.8.  Collision  Array  -  after  collision  is  detected  between  the  transmissions 
of  nodes  B  and  C 

matrix  reflected  another  frame  delivery  (other  than  the  one  just  made)  by  comparing 
the  Time_of-Next -Delivery  with  the  current  simulation  time.  H  they  axe  equal,  then 
the  frame  just  delivered  was  the  one  indicated  by  the  matrix.  If  the  simulation  time 
is  greater,  there  is  another  later  frame  awaiting  delivery  from  the  same  source  and 
the  matrix  element  should  not  be  changed. 

The  reasoning  behind  the  design  of  the  collision  mechanisms  is  necessary  for 
clarity.  It  is  not  unreasonable  to  change  the  Time_of_Next  .Delivery  every  time  the 
transmitter  requests  the  Channel  to  broadcast  a  frame.  This  is  because  a  node  can 
only  transmit  one  frame  at  a  time,  thus  consecutive  transmissions  from  the  same 
node  could  not  collide  with  one  another.  All  of  the  frames  transmitted  prior  to  the 
last  one  transmit  without  collision.  If,  however,  another  node  transmits  while  there 
are  a  number  of  pending  delivers  for  this  receiver,  the  Collision-Indicator  is  set  at  the 
start  of  the  interfering  transmission  so  that  any  frames  pending  delivery  after  this 
would  be  discarded.  When  a  collision  occurs  at  one  receiving  node,  it  does  not  have 
to  occur  at  all  the  receiving  nodes.  If  only  one  copy  of  the  frame  is  used,  discarding 
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it  leaves  nothing  to  deliver  to  the  dear  nodes.  Making  a  copy  of  the  frame  for  each 
receiving  node  prior  to  delivery  appears  to  be  a  sensible  approach  to  prevent  loss 
through  automatic  discard. 

The  collision  mechanism  also  resolves  the  problem  of  hidden  nodes  in  a  packet 
radio  network.  Resolution  occurs  when  the  Channel  examines  the  column  of  the 
Collision  Matrix  corresponding  to  the  receiver  and  gets  a  broadcast  request.  In  this 
example,  Node  B  can  talk  to  Node  D  and  Node  C  can  also  talk  to  Node  D,  but 
Node  B  and  Node  C  can  not  talk  to  each  other,  as  shown  in  Figure  3.9.  When 
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Figure  3.9.  Connectivity  Matrix 


Node  C  transmits  to  Node  D,  the  Channel  would  ask  Node  D  to  set  its  carrier 
flag.  Thus  Node  D  would  not  be  able  to  transmit  until  the  carrier  flag  was  cleared. 
However,  Node  B  remains  unaware  that  Node  C  is  tr2insmitting  to  Node  D.  As  far 
as  Node  B  is  concerned,  it  is  free  to  transmit.  When  it  transmits.  Node  A  will  hear 
it  and  the  Channel  will  have  Node  A  set  its  carrier  flag.  Yet,  Node  D  is  currently 
receiving  something  from  C  and  the  two  transmissions  coUide  at  Node  D  only.  The 
coUision  affects  only  the  receiving  node  involved. 

An  essential  component  of  the  Channel  is  a  Node  Array  for  keeping  track  of 
the  Node  modules’  unique  identifiers  and  memory  reference  variables.  The  Node 
Array  is  created  at  run-time  and  each  element  of  the  array  consists  of  a  unique  Node 
identifier,  possibly  the  callsign,  and  the  corresponding  memory  reference  variable 
(Figure  3.10).  By  creating  the  Node  Array  at  run-time  its  size  is  governed  by  the 
number  of  Nodes  the  user  requests,  thus  making  the  simulation’s  scenarios  dynamic. 
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Figure  3.10.  Node  Array 


Note  that  all  of  the  matrices  and  arrays  in  this  thesis  use  the  indices  of  A, 
B,  C,  and  D.  This  is  not  meant  as  an  implementation  detail,  but  to  show  that 
all  the  components  should  be  indexed  by  the  same  data  type.  When  the  Channel 
searches  for  information  concerning  a  given  Node,  it  will  use  the  same  variable  to 
search  in  each  component.  The  Channel  can  locate  the  particular  Node  it  wishes  to 
communicate  vdth  in  the  Node  Array.  It  will  set  a  variable  equal  to  the  memory 
reference  variable  for  that  Node,  and  pass  that  variable  to  a  generic  communications 
routine.  The  Channel  thus  has  only  one  set  of  routines  to  communicate  with  all  of 
the  Nodes  in  the  simulation. 

Another  method  for  ^ving  the  Channel  this  knowledge  about  the  Nodes  is  to 
program  a  unique  identifier  for  each  Node  into  the  Channel.  With  this  method  the 
simulation  would  need  to  be  recoded  and  recompiled  every  time  a  new  scenario  is 
analyzed.  Unfortunately,  this  forces  the  user  to  be  knowledgeable  about  the  simu¬ 
lation  language,  and  to  have  access  to  a  compiler  for  the  specific  language.  Thus 
far  the  researcher  has  attempted  to  keep  the  discussion  of  the  Channel  design  at  an 
abstract  level  to  avoid  specifying  implementation  details.  This  was  done  to  facihtate 
the  possibility  of  creating  a  simulation  using  any  language  or  any  hardware  platform 
desired. 

S.5  The  Nodes 

The  Channel  knows  about  the  Nodes,  through  the  Node  Array,  and  will  com¬ 
municate  with  them  in  this  simulation.  In  Section  3.4  the  discussion  of  the  Channel 
defined  a  field  of  the  Node  module,  called  the  carrier  flag.  Recall  firom  Section  3.3  that 
a  Node  is  defined  as  a  group  of  components,  a  computer,  a  TNC,  and  a  transceiver. 
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Since  the  TNC  is  the  component  that  will  hsten  to  the  radio  channel  for  a  transmis¬ 
sion,  it  is  appropriate  to  assign  it  the  carrier  flag.  In  the  real  world  the  broadcast 
radio  actually  does  the  hstening  to  the  channel  for  the  TNC.  However,  the  radio 
only  acts  as  an  interface  between  the  TNC  and  the  channel.  Also  for  the  purposes 
of  this  project,  it  is  not  necessary  to  simulate  the  method  of  transmission,  e.  g.  Ere- 
quency  Modulation  (FM),  Amplitude  Modulation  (AM),  etc..  This  factor  is  taken 
into  account  in  the  Channel’s  Probability  of  Bit  Error  Matrix.  Therefore,  the  radio’s 
hstening  function  and  the  carrier  flag  are  given  to  the  TNC. 

3.5.1  TNC  Module  If  both  AFITPAC  and  NOS  will  be  analyzed  using  this 
simulation,  then  two  types  of  a  TNC  must  be  designed:  1)  a  full  implementation 
which  includes  the  AX.25  protocoP  and  2)  a  hmited  implementation  which  includes 
the  KISS  protocol^.  AFITPAC  expects  the  TNC  to  provide  all  of  the  services  in 
the  AX.25  data  hnk  layer  and  expects  to  be  able  to  interface  with  the  TNC  using 
the  TNC’s  command  syntax.  The  NOS  package  expects  to  have  a  TNC  operating 
using  the  KISS  protocol  and  all  of  the  higher  level  protocols,  e.  g.  IP,  AX.25,  High 
Level  Data  lank  Control  (HDLC),  etc.,  are  found  in  the  NOS  software  modules.  The 
original  purpose  of  this  thesis  was  an  interface  the  AFITPAC  software,  therefore  the 
focus  will  be  placed  on  the  first  type  of  TNC  design. 

AX.25  Protocol  Module 

Control  Field  Handler  Basically,  AX.25  is  a  bit  level  protocol  and 
depends  on  bit  sequences  to  function.  The  Control  Field  processing  is  the  only 
part  of  the  AX.25  protocol  necessary  to  implement  at  this  level  of  detail.  All  other 
protocol  parts  can  be  implemented  using  higher  level  data  structures  and  behavioral 
modeling.  Since  the  control  field  is  always  eight  bits  long,  it  makes  sense  to  create 
it  as  a  fixed  array  of  length  eight.  Elach  element  of  the  array  can  be  any  data  type 

^For  protocol  information  see  Appendix  A,  Page  A-1 
^For  protocol  information  see  Appendix  A,  Page  A-3 
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supported  by  the  implementing  language.  For  this  project  a  boolean  data  type, 
TRUE  or  FALSE,  is  used,  since  this  most  closely  resembles  the  behavior  of  a  bit  to 
be  either  1  or  0.  It  is  then  possible  to  create  and  analyze  these  bit  patterns  for  every 
packet  transmitted  and  received.  The  receiving  Node  can  respond  according  to  the 
AX.25  protocol  once  the  Control  Field  has  been  examined.  Before  a  receiving  TNC 
should  bother  to  examine  the  packet's  Control  Field,  it  must  determine  if  the  packet 
is  destined  for  this  Node. 

Packet  Destination  Address  Handler  When  a  Node’s  TNC  re¬ 
ceives  a  packet,  it  checks  the  addresses  in  the  Destination  Field  and  the  elements  of 
the  Digipeater^  Array.  H  the  Destination  Field  matches  the  Node’s  address  the  TNC 
proceeds  vdth  processing  the  packet,  compares  it’s  Node’s  address  with  the  elements 
of  the  Digipeater  Array.  The  TNC  uses  the  following  algorithm  for  the  comparison 
to  assure  that  the  function  adheres  to  the  AX.25  standard: 

1.  H  there  are  no  more  elements  in  the  Digipeater  Array  then  exit 

2.  If  there  are  elements  in  the  Digipeater  Array  then  either  choose: 

(a)  The  selected  element  does  not  match  this  Node’s  jiddress  then 

i.  If  last  character  in  the  element  is  an  “H”  then  select  next  element 
and  go  to  1 

ii.  If  last  character  in  the  dement  is  not  an  “H”  then  discard  the  packet 
and  exit 

(b)  H  the  selected  dement  does  match  this  Node’s  address  then 

i.  Add  an  “H”  to  the  end  of  this  dement  and  place  back  in  the  array 

ii.  Set  the  Transmit.Source  field  of  the  frame  to  this  Node’s  address 

^Digipeater  -  “digital  repeater,  a  device  that  receives,  temporarily  stores  and  retransmits 
(repeats)  packet-radio  transmissions  that  are  specifically  addressed  for  routing  through  the 
digipeater(12) 
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Hi.  Request  the  Channel  to  broadcast  this  frame 
iv.  Dispose  of  the  local  copy  of  this  frame  and  exit 

The  “H”  is  added  on  to  the  end  of  the  element  that  matches  this  Node’s  address 
to  indicate  that  this  packet  Has- Been- Repeated.  The  “H”  was  chosen  to  coincide 
with  the  AX.25  name  for  this  bit,  the  “H-bit”.  If  the  frame  happens  to  return  to 
this  node,  the  TNG  will  not  recognize  this  Digipeater  Array  element,  because  it  is 
not  an  exact  match  for  its  own  address. 

The  order  in  which  the  elements  of  the  Digipeater  Array  are  scanned  is  im¬ 
portant  because  it  corresponds  to  the  order  in  which  the  packet  is  routed  through 
the  digipeating  Nodes.  If  the  Node’s  address  does  not  match  the  selected  element 
and  this  element  ends  in  an  “H”,  then  TNG  can  go  on  to  the  next  element.  This 
procedure  prevents  the  packet  from  being  digitally  repeated  by  two  nodes  at  the 
same  time. 

For  example,  given  the  Connectivity  Matrix  in  Figure  3.11  and  that  Node  B 
needs  to  send  a  message  to  Node  A,  Node  B  has  two  routes  to  get  the  message  to 
Node  A:  1)  from  Node  B  to  Node  D  to  Node  C  to  Node  A  {B—  >  D—  >  C—  >  A) 
and  2)  from  Node  B  to  Node  C  to  Node  A  B—  >  C—  >  A).  Node  B  does  not 
know  about  the  direct  connection  to  Node  C  and  so  it  decides  to  use  the  first  route. 
Figure  3.12  shows  an  example  of  the  AX.25  packet  header. 

When  Node  B  asks  the  Channel  to  broadcast  this  packet'*.  Nodes  D  and  C 
receive  a  copy.  Node  D  finds  that  its  address  is  the  first  in  the  Digipeater  Array 
and  therefore  Node  D  digitally  repeats  the  packet.  Node  C  processes  the  packet 
and  finds  Node  D’s  address  is  the  first  dement  in  the  array,  discovers  no  “H”  at  the 
end  of  the  dement,  and  discards  the  packet.  Node  D  now  requests  the  Channel  to 
broadcast  this  packet  whose  AX.25  packet  header  is  Uke  Figure  3.13.  Nodes  B  and 

^The  word  packet  is  used  here  to  remain  consistent  with  the  level  of  the  design.  The  Node  would 
still  send  the  Channel  a  frame  and  all  the  fields  associated  with  it. 
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Figure  3.11.  Connectivity  Matrix  for  Digital  Repeating  Example 
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Figure  3.12.  AX.25  packet  Address  Header  for  Digital  Repeater  Example 
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Figure  3.13.  AX.25  packet  Address  Header  for  Digital  Repeater  Example 

C  receive  a  copy  of  the  packet.  Node  B  does  not  find  its  address  anywhere  in  the 
header,  because  a  receiving  node  does  not  examine  the  Source  Address  and  discards 
it.  Node  C  examines  the  Digipeater  Array,  finds  DH  in  the  first  element,  it  finds 
that  the  element  ends  in  an  “H”,  and  finds  its  address  is  the  next  element  in  the 
array.  Node  C  processes  the  packet  for  digital  repeating  and  makes  a  request  to  the 
Channel  to  broadcast  this  packet,  whose  AX.25  packet  header  boks  hke  Figure  3.14. 
Nodes  B,  D,  and  A  all  receive  a  copy  of  the  packet.  Node  B  discards  the  packet 
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Figure  3.14.  AX.25  packet  Address  Header  for  Digital  Repeater  Example 

as  before.  Node  D  examines  the  Digipeater  Array,  it  does  not  find  its  address  in 
any  of  the  elements  and,  therefore  discards  the  packet.  If  Node  C  were  allowed 
to  digitally  repeat  the  first  packet  (because  its  Node  address  was  in  the  Digipeater 
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Array)  Node  A  would  have  received  two  copies  of  the  same  packet.  Node  A  only 
receives  one  copy  of  the  packet  and  proceeds  to  analyze  the  Control  Field. 

Behavioral  modules  could  be  designed  for  the  rest  of  the  AX.25  protocol  in  a 
similar  fashion  to  the  digital  repeating  module.  The  digital  repeating  function  of  the 
TNG  is  the  protocol’s  simplest  part  because  it  does  not  require  any  acknowledge¬ 
ments  or  control  mechanism  handling. 

PC  Interface  Module  This  way  of  handling  the  digital  repeating  algo¬ 
rithm  using  the  “H”  bit  is  an  example  of  how  protocol  parts  can  be  behaviorally 
implemented  using  higher  level  data  types.  The  method  detailed  only  deals  with 
the  data  link  layer  protocol  found  in  the  TNC.  The  interfacing  of  the  TNC’s  data 
Unk  layer  with  the  rest  of  the  model  has  not  been  addressed.  AFITPAC  expects 
to  control  the  TNC  by  using  the  normal  command  hne  syntax.  For  example,  when 
AFITPAC  establishes  a  connection  to  another  PRU  it  hterally  sends  “c  NODEl 
via  REPEATERl”,  one  character  at  a  time  to  the  TNC.  AFITPAC  uses  assembly 
language  routines  to  communicate  with  the  port  on  the  PC  connected  to  the  TNC. 
Therefore,  AFITPAC  could  be  link  to  the  simulation  by  constructing  a  PC  interface 
module  that  would  replace  these  functions,  e.g.  Ser_send(),  Ser_recv(),  etc.,  and  then 
translate  the  TNC  command  syntax  into  service  requests  of  the  TNC  simulator. 

3.5.2  PC  Module  In  the  real  world  AFITPAC  and  NOS  would  operate  on 
a  personal  computer.  Thus  the  module  in  which  these  packages  operate  is  called 
the  PC  Module.  The  PC  module  contains  the  software  package  to  be  analyzed,  an 
interface  to  the  programs  for  the  simulator,  and  a  simulated  user.  The  simulator’s 
interface  to  the  programs  is  needed  so  that  the  parameters  of  the  software  packages 
can  be  changed.  This  interface  will  either  require  modifications  to  AFITPAC  and 
NOS  or  use  direct  calls  to  the  packages’  internal  functions. 

The  changing  of  these  parameters  would  effect  the  performance  of  the  packages 
automated  functions  and  thus  the  amount  of  traffic  generated  on  the  network.  It 
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is  not  necessary  however,  to  interact  with  the  software  to  generate  normal  message 
tralHc.  The  simulation  employs  a  user  to  test  total  efficiency  and  efficacy,  and  is 
designed  as  follows: 

1.  A  random  number  generator  to  simulate  the  rate  of  traffic  generation.  Using 
diverse  random  distributions,  different  traffic  loads  can  be  simulated.  Most 
random  number  generators  return  a  value  between  0.0  and  1.0.  When  the 
returned  value  exceeds  a  defined  threshold  a  message  transmission  occurs. 

2.  A  random  number  generator  to  simulate  the  length  of  the  traffic  generated. 
In  this  case,  the  distribution  is  partitioned  into  bins  from  zero  to  a  defined 
maximum  message  length.  When  the  value  returned  by  the  random  number 
generator  falls  in  a  bin,  the  size  of  the  message  is  determined. 

3.6  Summary 

The  chapter  opened  with  a  discussion  of  modularity  and  how  it  related  to 
simulation  design.  The  concept  of  discrete  components  was  introduced  to  provided 
a  mechanism  by  which  a  modular  simulation  could  be  designed.  The  layers  of  the  OSI 
network  model  were  associated  with  the  discrete  components  to  demonstrate  how 
a  computer  communications  network  could  be  simulated.  By  examining  the  layers 
of  the  network  model  a  design  for  a  packet  radio  network  simulation  was  proposed. 
This  simulation  model  included  a  Channel  module  and  a  Node  Module.  The  Channel 
Module  was  broken  down  in  to  its  subcomponents:  Connectivity  Matrix,  Probability 
of  Bit  Error  Matrix,  Collision  Matrix,  and  Node  Array.  E^ch  one  of  these  was 
described  in  detail.  In  describing  the  Channel  module  a  message  unit  called  a  frame 
was  developed.  The  frame  was  the  message  unit  passed  between  Nodes  by  the 
Channel.  The  Node  module  was  also  divided  up  into  its  subcomponents:  TNC 
module  and  PC  module.  The  TNC  was  decomposed  further  into  an  AX.25  module 
and  a  PC  Interface  module.  The  AX.25  module  contained  the  Control  Field  Handler, 
which  evaluated  the  contents  of  a  packets  control  field.  It  also  includ''d  an  Packet 


3-21 


Destination  Address  Handler,  that  determined  if  the  Node  was  the  destination  for  a 
received  packet  or  if  the  Node  was  to  digitally  repeat  the  packet.  The  remainder  of 
the  AX.25  protocol  was  not  explicitly  discussed,  however  it  was  mentioned  that  it 
could  be  implemented  behaviorally  using  higher  level  data  types.  The  PC  Interface 
module  was  introduced  as  a  gateway  between  the  software  packages  being  analyzed 
and  the  simulated  TNG.  A  brief  description  was  then  given  of  the  subcomponents 
the  PC  module:  Interface  to  Programs  and  simulated  user. 

This  closes  the  discussion  of  a  packet  radio  network  simulator  design.  The  Node 
module  components  are  defined  in  less  detail  because  of  developmental  problems  in 
the  early  stages  of  their  design.  As  the  development  cycle  progressed  the  details 
of  the  design  suffered  when  coding  problems  occurred.  The  exact  nature  of  these 
problems  is  discussed  next,  in  Chapter  IV. 
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IV.  Conclusions  k  Recommendations 


4-1  Introduction 

Chapter  IV  begins  with  a  description  of  problems  encountered  with  the  PC- 
DOS  version  of  MODSIM  These  problems  slowed  the  development  of  a  work¬ 

ing  simulation  and  eventually  led  to  the  project's  end.  Following  the  discussion  of 
problems,  the  author  makes  recommendations  for  further  research  and  development. 

4.2  Problems  with  MODSIM  - 

The  first  problem  was  that  a  major  concept  in  the  MODSIM  language  did 
not  function  as  documented  in  the  manual.  The  problematic  concept  was  EXPORT- 
ing  Object  types  in  the  definition  module  for  use  by  other  Objects.  H,  for  example, 
a  “parent”  object  was  to  tell  another  object,  called  “child”,  to  perform  a  function, 
MODSIM  requires  that  the  reference  variable  used  to  command  the  child  to 
do  something  be  of  type  “child”.  It  is  desirous  to  define  the  “parent”  as  having  a 
field  of  type  “child”  object.  Of  course,  the  “child”  object  will  want  to  respond  to 
the  “parent”  object,  therefore,  it  will  need  to  have  a  field  of  type  “parent”  object. 
The  MODSIM  manual  states  each  object  should  EXPORT  its  definition  for 
use  by  the  other  object.  This  does  not  work!  Attempting  to  compile  two  objects, 
each  having  a  field  of  the  other  object  type,  results  in  a  (yclic  definition  error. 

After  some  attempts  to  work  around  this  problem,  the  manufacturer  ¥ra.s  con¬ 
tacted.  CACI  Products  Company  responded  that  this  was  indeed  a  known  problem 
with  the  compiler.  There  are  no  plans  to  correct  the  problem  because  they  no  longer 
plan  to  support  the  DOS  version  of  the  package.  They  were  able,  however,  to  pro¬ 
vide  a  workable  solution  to  the  problem.  Define  the  “parent”  and  “child”  objects  as 
having  a  field  of  type  ANYOBJ,  which  is  a  generic  reference  variable  to  an  object. 
However,  do  not  tell  an  ANYOBJ  to  do  anything,  because  the  information  about 
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its  methods  are  unknown.  In  order  to  use  this  solution,  IMPORT  the  object  type 
into  the  implementation  module.  For  example  the  “parent”  object’s  implementa¬ 
tion  module  would  contain  the  Hne;  FROM  childmodule  IMPORT  ChildObjectType;. 
Then  the  “parent”  object  coerces  AN  YOB  J  into  a  “child”  object  type,  a  concept 
similar  to  that  of  type  casting  in  C'*"*'  and  ADA.  Then  use  this  coerced  variable 
to  tell  the  child  to  do  something.  This  solution  did  work  and  allowed  for  further 
simulation  development. 

The  second  problem  encountered  was  with  the  use  of  the  monitor  objects. 
These  are  a  special  class  of  objects  which  MODSIM  11^^  provides  for  the  collection 
of  data  concerning  records  and  fields.  “Monitoring  may  be  specified  as  being  left, 
right,  or  left  and  right.  Left  monitoring  means  that  any  time  the  variable  or  field  is 
updated  monitoring  methods  that  you  have  specified  will  be  invoked.  Right  moni¬ 
toring  invokes  the  specified  methods  whenever  the  variable  or  field  is  referenced. (3)” 
There  are  three  advantages  of  using  monitor  cl2iss  objects;  1)  less  code  is  needed  for 
monitoring  variables  and  fields,  2)  changes  to  the  monitoring  functions  only  have  to 
be  made  in  the  monitor’s  definition,  and  3)  the  monitoring  functions  can  be  enabled 
or  disabled  without  effecting  the  simulation.  The  monitor  objects  were  to  be  used 
to  track  frames  in  the  PRNET  simulation.  An  attempt  to  monitor  two  of  the  same 
type  of  variables  in  the  same  object  resulted  in  the  simulation  test  ending  in  error, 
specifically  “Unidentified  FPE”.  The  MODSIM  manual  only  repeated  what  the 
error  messages  said  on  the  screen  and  provided  no  further  explanation.  Confidence  is 
high  that  monitoring  two  variables  is  the  problem  because  when  one  of  the  monitors 
is  removed  the  test  program  executed  properly. 

The  most  challenging  problem  came  when  testing  out  a  generic  record  queue 
and  timer.  The  timer  module  tested  fine,  the  record  queue  did  also,  but  it  was 
the  combination  of  the  two  that  presented  difficulties.  Every  time  the  simulation 
was  run  it  would  run  out  of  memory.  A  small  C'*"''  routine  was  written  to  show 
the  amount  of  available  memory  and  interfaced  it  into  the  simulation.  The  record 
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queue  was  first  tested  to  ascertain  that  when  items  were  removed  from  the  queue 
that  the  memory  was  being  freed.  The  memory  was  being  allocated  and  freed  just 
as  expected.  The  heap  size  declined  as  more  items  were  created  and  added  to  the 
queue  and  increased  as  they  were  removed  and  disposed.  The  researcher  then  tested 
the  timer  module  with  similar  results.  The  combined  model  was  a  simple  traffic 
fight  having  two  queues  (to  represent  the  intersection),  four  complex  records  (to 
represent  cars),  and  a  timer  (to  make  the  fights  change).  A  total  of  twenty-three  car 
records  and  the  other  three  objects  were  used.  The  simulation  run  with  the  memory 
checker  resulted  in  more  than  half  of  the  available  memory  consumed  or  tied  up. 
As  the  simulation  ran,  the  memory  addresses  were  not  being  reused  in  the  event 
tables  as  expected.  They  simply  kept  increasing  until  there  were  only  144  bytes  left 
and  the  simulation  halted.  The  computer  used  to  execute  this  model  has  a  total  of 
four  megabytes  of  memory,  which  seemed  adequate.  However,  it  appears  the  DOS 
extender,  provided  with  MODSIM  H^^,  is  used  only  for  compiling  and  has  no  effect 
on  run-time  modules.  The  entire  simulation  is  loaded  into  the  available  base  640K  of 
memory  on  the  computer.  This  suspicion  was  confirmed  by  the  manufacturer  when 
they  were  called  about  running  out  of  memory  during  compile  time. 

This  simple  traffic  fight  model  indicated  that  there  would  not  be  enough  mem¬ 
ory  on  a  PC  to  run  a  PRNET  simulation.  The  researcher  believes  that  a  simulation 
including  at  least  ten  Nodes,  would  be  needed  to  produce  results  of  any  significance. 
A  simulation  of  this  size  would  require  twenty  or  more  record  queues,  twenty  or  more 
timers,  and  a  large  number  of  frame  records.  These  would  just  represent  the  basic 
elements  of  the  TNC  module  and  does  not  include  the  remaining  Node  or  Channel 
module  components.  Therefore,  it  was  decided  to  stop  development  of  the  PRNET 
simulation  on  a  personal  computer. 
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4-3  Recommendations 

The  packet  radio  simulation  that  allows  an  application  developer  to  analyze  the 
performance  impact  of  their  work  on  a  packet  radio  network  is  a  valuable  tool  and 
should  be  pursued.  Wireless  networks  are  beginning  to  make  their  way  into  the  local 
area  network  arena.  As  the  technology  improves,  wireless  wide  area  networks  will 
become  more  popular.  A  packet  radio  network  can  provide  the  tjrpe  of  long  dist<ince 
connections  necessary.  There  is  great  potential  for  today’s  advanced  network  appli¬ 
cations  to  take  advantage  of  this  medium’s  ability  to  connect  nodes  large  distances 
apart.  Development  of  a  PRNET  simulation  tool  could  be  used  in  the  development 
of  more  bandwidth  efficient  protocols  and  more  advanced  applications.  Therefore, 
it  is  recommended  that  the  development  of  a  PRNET  simulation  be  pursued  on  a 
hardware  platform  other  than  a  personal  computer.  In  the  researcher’s  opinion,  if 
MODSIM  is  available  for  use  on  a  Sun-3,  Sun-4,  SPARC,  VAX/VMS,  or  Unix 
system  that  it  should  be  used  because  it  provides  a  simple  interface  capability  to 
C.  If  MODSIM  is  not  available,  the  PRNET  design  proposed  in  this  thesis 
cotdd  be  used  to  develop  a  simulation  in  ADA  or  other  languages,  which  provide  an 
interface  to  C. 

Once  the  simulation  is  working  improvements  could  include  elaboration  of  the 
Channel  model.  The  matrices.  Connectivity  and  Ft,  currently  used  make  the  as¬ 
sumption  of  equal  transmission  power  and  equal  reception  capabilities.  It  would 
make  the  Channel  more  realistic  if  the  Connectivity  Matrix  took  into  consideration 
transmitter  power,  propagation  losses,  and  antenna  gain  to  determine  which  nodes 
could  hear  each  other.  Also  if  the  Ft  Matrix  reflected  that  a  radio  path  between  two 
nodes  might  not  be  two  directional.  This  suggestion  is  the  result  of  a  recommen¬ 
dation  by  Phil  Karn  to  use  transmitter  power  control  to  increase  frequency  usage. 
Karn  proposes  that  by  using  a  channel  access  scheme  that  adjusts  the  power  to  a 
level  necessary  to  just  hear  the  next  node  you  need  to  talk  to,  the  throughput  of  a 
band-limited  channel  could  be  increased(13). 
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Another  recommended  modification  of  the  simulation  is  to  the  Node  modules. 
Each  Node  could  keep  an  array  similar  to  that  of  the  Channel’s  Node  Array,  except 
this  would  be  a  Channel  Array.  By  creating  different  channels,  the  simulation  could 
take  into  account  simultaneous  transmission  in  different  frequency  bands.  Further¬ 
more,  it  could  be  used  to  simulate  the  ability  of  some  Nodes  to  provide  gateway 
services  between  different  frequency  channels. 

An  area  of  great  interest  is  the  security  of  a  packet  radio  network.  The  tracing 
ability  of  the  NOS  package  could  also  be  used  for  spying  on  a  packet  radio  network. 
An  individual  could  turn  tracing  on  and  log  all  of  the  message  traffic  to  disk  fr)r 
later  analysis.  Both  NOS  and  AFITPAC  provide  the  ability  to  transmit  encrypted 
messages.  However,  the  packet  header  information  is  transmitted  in  the  dear,  leaving 
the  network  subject  to  traffic  flow  analysis.  This  problem  could  be  resolved  if  the 
entire  transmitted  packet  was  encrypted.  The  NOS  package  expects  to  see  a  TNG 
operating  in  Keep-It-Simple-Stupid(7)  (KISS)  mode,  which  allows  the  host’s  software 
to  have  control  over  the  TNG  functions  at  the  lowest  possible  level{7).  In  this  mode 
of  operation  the  TNG  “simply  converts  between  synchronous  HDLG,  spoken  on  the 
full-  or  half- duplex  radio  channel,  and  a  special  asynchronous,  full  duplex  frame 
format  spoken  on  the  host\TNG  link.(7)”  Therefore,  it  is  recommended  that  an 
encryption  software  module  or  device  be  developed  to  place  between  the  KISS  TNG 
and  computer  to  provide  the  security  measures  necessary. 


# 
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Appendix  A.  Definition  of  Terms 


A 

AX.  25  -  The  link-layer  packet-radio  protocol  based  on  the  CCITT  X.25  packet¬ 
switching  protocol.(12)  For  complete  details  of  the  workings  of  the  AX.25 
protocol  refer  to  ,  AX.25  Amateur  Packet-Radio  Link-Layer  Protocol,  Ver¬ 
sion  2.0,  October  1984{Q),  which  is  available  from  the  American  Radio 
Relay  League  (ARRL). 


C 

Carrier  Sense  Multiple  Access  -  (a)  a  channel- access  arbitration  scheme  in  which 

packet-radio  stations  hsten  for  the  presence  of  a 
carrier  on  a  channel  before  transmitting. (12)  (b) 
a  characteristic  of  network  hardware  that  oper¬ 
ates  by  allowing  multiple  stations  to  access  to  a 
transmission  medium  by  Ustening  to  see  if  it  is 
idle. (8)  (c)  when  a  station  has  data  to  send,  it 
first  fistens  to  the  channel  to  see  if  anyone  else  is 
transmitting.  If  the  channel  is  busy,  the  station 
waits  until  it  becomes  idle.  When  the  station 
detects  an  idle  channel,  it  transmits  a  frame.  If 
a  collision  occurs,  the  station  waits  a  random 
amount  of  time  and  starts  all  over  again. (19) 

Channel  -  the  module  used  to  represent  a  single  radio  fre¬ 

quency  free  space  transmission  medium. 

Collision  Matrix  -  a  matrix  used  to  keep  track  of  pending  frame  de¬ 

liveries  to  a  simulation  Node.  It  is  used  to  oom- 
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pensate  for  the  instantaineous  delivery  of  frames 
to  nodes  in  a  discrete  event  simulation. 


D 


Datagram  protocol- 


Delivery  delay  - 


Digipeater 


a  Network-layer  protocol  that  transfers  each  packet  inde¬ 
pendently  along  the  best  available  route;  also  called  con¬ 
nectionless  protocol.  (12) 

the  time  it  take  to  pass  the  entire  contents  of  a  packet 
from  transmitter  to  receiver.  It  includes  transmission  time, 
propagation  delay,  and  reception  time. 

digital  repeater,  a  device  that  receives,  temporarily  stores 
and  then  transmits  (repeats)  packet-radio  transmissions 
that  are  specifically  addressed  for  routing  through  the  digipeater.(12) 


E 

Ethernet  Tkansceiver  -  a  device  which  clamped  to  a  coaxial  cable  so  that  it  makes 

contact  with  the  inner  core.  The  transceiver  contains  the 
electronics  that  handle  the  carrier  detection  and  collision 
detection.  When  a  collision  is  detected,  the  transceiver 
also  put'>  a  special  invahd  signal  on  the  cable  to  insure 
that  all  other  transceivers  also  realize  that  a  collision  has 
occurred.(19) 


G 

GILLAROO  -  “cryptographic  board  encrypts  data  by  using  a  cryptographic  key 
(loaded  from  a  paper  tape)  which  converts  the  data  into  pairs  of 
output  characters;  the  first  character  is  a  capitol  letter  between  A 
and  P,  and  the  second  is  a  lower  case  letter  between  a  to  p.  No 
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control  characters  other  than  pause  transmission  (control  S),  resume 
transmission  (control  Q),  and  end  of  file  (control  Z)  are  output  from 
the  device  while  in  secure  mode.  (15)” 


H 

HDLC  -  {High-Level  Data  Link  Control)  a  link  level  protocol  standard  by 

ISO.  CCITT  later  adapted  HDLC  for  its  link  access  protocol  (LAP) 
used  with  X.25  networks.  HDLC  is  increasingly  important  to  the 
Internet  because  Packet  Switch  Node  (PSN)  interfaces  now  use  it 
to  transfer  frames  between  the  host  and  PSN. (8) 

Hidden  Nodes  -  a  packet  radio  station  that  can  be  heard  by  only  one  of  two  other 
stations  that  are  connected;  in  such  a  situation,  the  two  stations 
that  cannot  hear  each  other  transmit  simultaneously,  which  results 
in  the  reception  of  interference  or  a  packet  collision  by  the  third 
station(12). 

HOP  -  the  equivalent  of  an  edge  on  a  network  graph.  The  number  of 

point-to-point  transmissions  xised  to  deliver  a  message  from  source 
to  destination. 

K 

KISS  -  an  acronym  for  “Keep  It  Simple  Stupid,”  a  Link-layer  nonprotocol  for  se¬ 
rial  input  and  output  that  supports  Serial  Line  Interface  Protocol  (SLIP), 
written  by  Mike  Chepponis.(7,  12) 

M 

MODSIM  H^^  -  “the  Modidar  Simulation  language  is  a  general-purpose,  modu¬ 
lar,  block  structured  language  which  provides  support  for  object- 
oriented  programming  and  discrete  event  simulation.  It  is  in- 
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tended  to  be  used  for  building  large  process-based  discrete  event 
simulation  models  through  modular  and  object-oriented  develop¬ 
ment  techniques.  (5)” 

Module  -  any  independent  unit  which  is  part  of  a  large  system.  Microcom¬ 

puter  and  other  systems  may  be  made  from  several  modules,  a 
piece  or  segment  of  a  whole;  an  incremental  block(6). 

N 

Node  -  (a)  the  name  of  a  module  in  this  thesis  that  represents  the  collection  of 
a  TNG,  a  computer,  and  a  simulated  user,  (b)  any  terminal,  station,  or 
communications  computer  in  a  computer  network{6).  (c)  a  junction  point 
within  a  network(12). 

P 

Packet  -  (a)  In  communications,  a  short  (1000-2000  bits) 

block  of  data  prefixed  with  addressing  and  other 
information  for  control  that  is  used  to  carry  in¬ 
formation  through  a  packet-switching-network(6).(b)The 
unit  of  data  sent  across  a  packet  switched  net¬ 
work.  The  term  is  used  loosely.  While  some 
Internet  hterature  tises  it  to  refer  specifically  to 
data  sent  across  a  physical  network,  other  ht¬ 
erature  views  the  Internet  as  a  packet  switching 
network  and  describes  IP  datagrams  as  packets(8). 

PING  -  [Packet  InterNet  Cropper)  The  name  of  a  pro¬ 

gram  used  in  the  Internet  to  test  reachability 
of  destinations  by  sending  them  an  ICMP  echo 
request  and  waiting  for  a  reply.  The  term  has 


survived  the  original  program  and  is  now  used 
like  a  verb  as  in,  “please  ping  host  A  to  see  if 
it  is  alive.”  (8) 

PRNET  -  Packet  Radio  Network,  a  computer  network  con¬ 

sisting  of  PRUs. 

Probability  of  Bit  Error  Matrix  -  a  component  of  this  project  used  to  hold  the 

probability  of  bit  error  between  a  pair  of  PRUs. 
Probability  of  bit  error  is  the  chance  that  a 
transmitted  bit  will  be  received  incorrectly. 

PRU  -  Packet  Radio  Unit,  each  unit  consists  of  a  ter¬ 

minal  or  computer,  a  TNG,  and  a  radio  transceiver. 

R 

Routing  Ihble  -  a  table  used  to  track  assignments  of  communications  paths  for 
message  delivery (6) 

T 

Terminal  Node  Controller  (TNG)  -  an  Amateur  Radio  packet  assembler /disassembler; 

it  may  or  may  not  include  a  modem(12) 

Topology  -  In  network  terminology,  describes  the  physi¬ 

cal  or  logical  placement  of  nodes  (stations)  in 
a  computer  network  system  or  configurations  (6) 

Transmit  Queue  -  a  hst  used  to  keep  track  of  the  simulation 

frames  waiting  to  be  transmitted  by  the  TNG. 
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u 


Uuencode\Uudecode  - 


encode/decode  a  binary  file  for  transmission  via  mail.  Out¬ 
put  from  uuencode  is  all  ASCII  printable  text  from  a  binary 
input  file.  Output  from  uudecode  is  a  binary  file  from  an 
uuencoded  file. 
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